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1 .0  Introduction 


t/e 


This  report  summarizes  the  work  performed  during  the  ninth  quarter  of 
this  contract,  from  December  15,  1983  to  March  14,  1984.  vThe  work  in  this 
quarter  concentrated  on  three  areas:  scheduling  algorithms  based  on 
bidding,  scheduling  algorithms  for  systems  with  hard  real-time  constraints 
and  on  scheduling  based  on  stochastic  learning  automata.  Section  2  of  this 
report  describes  the  progress  made  in  these  areas. 


We  also  note  that  the  paper  entitled  "Bayesian  Decision  Theory  and  It's 
Application  to  Decentralized  Control  of  Job  Scheduling"  produced  earlier  in 
this  contract  has  been  accepted  for  publication  in  IEEE  Transactions  on 
Computers. 


2.0  Main  Text 


2.1  Bidding 

In  this  quarter  we  concentrated  on  designing  extensions  to  our 
simulation  program  which  implements  our  decentralized  bidding  algorithm 
(described  in  detail  in  previous  reports).  As  a  reminder,  the  main  idea 
behind  the  algorithm  is  to  treat  all  the  information  needed  to  make  a 
scheduling  decision  as  input  to  a  McCulloch  Pitts  neuron.  If  the 
excitations  of  the  neuron  surpass  a  threshold  then  a  task  is  not  considered 
as  a  candidate  for  bidding,  else  it  is.  The  extensions  worked  on  in  this 
quarter  involve  two  areas.  The  first  is  modifying  the  model  of  a  process 
from  simply  one  object  with  size  x  bytes  to  considering  the  a  process  to  be 
collection  of  objects  each  of  different  size.  Further,  these  objects  of  a 
process  are  modeled  to  have  certain  characteristics  including  whether  they 
are  unshared,  shared  serially  or  shared  simultaneously.  The  second 
extension  involved  developing  formulas  for  inclusion  in  our  McCullock  Pitts 
neuron.  The  approach  will  be  to  incrementally  include  these  formulas  into 
our  simulation  model.  We  now  present  the  formulas. 


Factors  for  the  McCulloch  Pitts  Neuron 


Individually  the  factors  described  here  are  simple,  but  taken  together 
they  provide  for  a  very  sophisticated  scheduler.  A  major  research  goal  is 
to  normalize  the  weights,  W,  of  the  various  factors,  discover  dependencies 
among  the  weights  and  adapt  them  as  a  function  of  system-wide  workload. 

1 .  Queue  Length  Factor  -  QL 
Consider 

-  length  of  the  queue  of  jobs  waiting  to  become  active 

(e.g.,  because  the  level  of  multiprogramming  has  been 
reached  at  this  host) 


Q,  -  The  number  of  active  tasks  at  this  site 
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Then 
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Note 
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Queue  lengths  for  certain  resources  are  used  in  other  factors  (see 
the  segments  shared  serially  factor  and  position  in  wait  queue 
factor) . 


2.  Memory  Factor  -  M. 
Consider 


M 

M 

M 


AVAIL  “  amount  of  free  memory  at  this  host 
current  "  amount  of  memory  assigned  to  this  task 
new  -  new  memory  requirement  of  this  task 


Then 


m-wm 


[(MAVAIL  "  (Mnew  ~  Mcurrent)) j 
MAVAIL 


:  The  memory  requirement  of  a  task  at  time  t  is  the  sum  of  its  segment 
sizes.  The  fact  that  some  of  its  segments  may  be  simultaneously 
shareable  is  used  in  the  next  factor. 


Simultaneously  Shared  Segments  Factor  -  Si. 

Let  Ngi  ■  the  number  of  tasks  sharing  this  segment  of  task  P 


Initially  we  consider  two  forms: 
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N 
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Then  Si  -  l  Wgl  Ngl  or  l  Wgi  e 
o  a 


Si 


where  o  -  the  set  of  this  task's  shared  simultaneously  segments 


Segments  Shared  Serially  Factor  -  Se 


Let  NSe  -  the  number  of  tasks  waiting  for  this  segment  at  this  site 

SE'S  “sAe 

0 

where 

o  -  the  set  of  this  task's  shared  serially  segments. 


5.  Distributed  Group  Factor  ■  DG. 


Let  Ndg  -  the  number  of  tasks  of  this  distributed  group  at  this  host 


We  have  two  forms  for  this  factor: 


DG  -  «W„„  ( 


DG  TfDG^T 


or 


DO  -  «WDG  e 
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where  if  N_. _  -  0  then  5-0,  else  5 

Ub 


6.  Cluster  Factor  -  C. 

Assuming  that  this  task  is  a  member  of  a  cluster,  then  Let  NQ  -  to 
number  of  tasks  in  this  cluster,  Nc  fc  1 . 

N  -  total  number  of  tasks  of  this  cluster  at  this  site, 
cs 

NCS*  K 


Two  forms  of  C  are: 


where  a  is  a  normalizing  constant. 


7.  Priority  Factor  -  Pr. 

Let  the  priority  of  this  task  be  Pp. 


Then  Pr  -  WprPp. 


8.  Precedence  Factor  -  P. 

At  this  time  we  consider  precedence  constraints  between  tasks  of  the 
form,  task  A  must  precede  task  B  (or  equivalently  task  B  must  not  begin 
until  task  A  completes).  We  also  assume  that  task  B  would  in  general,  use 
some  of  the  output  produced  by  A.  Therefore,  if  task  B  were  at  the  same 
host  as  task  A  it  would  be  beneficial  for  it  to  remain  there  as  far  as 
obtaining  (some  of)  its  input  was  concerned.  In  general,  a  task  can  have 
any  number  of  preceeding  tasks. 

Let  0  -  the  sum  total  (size)  of  the  output  produced  at  this  site  for 
this  task. 

Then  we  can  consider  the  incentive  for  keeping  this  task  here  to  be 
either: 


On  the  other  hand,  if  task  B  were  at  another  site  then  the  output  produced 
by  A  would  be  subject  to  a  communication  cost  providing  incentive  to  move 
task  B.  We  represent  this  incentive  by 

-V0’  C0 


-  [Wp,,,e°’c0]6 


where  O’ 


total  amount  of  output  (size)  produced  at  other  sites  for 
this  task, 


CQ  -  estimated  cost  per  unit  size  of  moving  the  output  to 
this  host,  and 


5  -  0  if  O'  is  zero,  otherwise  6-1. 


Then  P  -  Wp0  -  Wp"0'  CQ 


P  -  Wp*  e°  -  [Wp’"e°'c0]6. 


9.  CPU  time  requirement  factor  -  T. 


Let  Ty  -  time  used  so  far 

T0  -  time  required  ( if  known) . 

n 


We  have  two  forms: 


T  -  W  (-Si) 

wcpuvtr; 


<w 

T  -  W’CPU  e  • 

10.  Position  in  Wait  Queue  Factor  -  W^.. 

Let  Wq  -  position  in  wait  queue  of  resource  j  where  j  is  a  type  of 

resource  that  is  available  elsewhere  (e.g.,  printers  and  other 
I/O  devices). 


Wt  “  WWt  WQ 


Wt  -  WHt  e 


1 1 .  Inhibitors 

I1  -  this  task  moved  x  times  already,  so  I1  -  0,  else  1 


6 


Ig  ■  this  task  needs  a  resource  that  is  fixed  at  this  site,  so 
I2  -  0,  else  1 

Then  the  McCulloch  Pitts  Neuron  (MPN)  in  its  final  form  could  be: 


MPN  -  |  |  1.(1  W.  .  Factor  ) 

i-1,2  j  J  J 

or 

MPN  -  I1  .  I2  .  [QL  +  M  +  Si  +  Se  +  DG  +  C  +  Pr  +  P  +  T  +  Wt] 


In  this  formula  DG,  C  and  P  use  network-wide  information.  Another 
aspect  of  our  research  is  to  extend  some  of  the  other  factors  to  deal  with 
network-wide  information  such  as  M  and  T  as  well  as  including  additional 
factors  such  as  the  number  of  outstanding  bids. 

2.2  Real  Time  Constraints 


This  research  involves  scheduling  periodic  and  nonperiodic  tasks,  with 
real-time  constraints,  on  processors  in  a  network.  A  nonperiodic  ta3k  is 
one  that  occurs  in  the  system  just  once  and  at  unpredictable  times.  Upon 
arrival,  it  is  characterized  by  its  deadline  and  its  computation  time.  No 
priorities  are  assigned  to  tasks  other  than  those  induced  by  deadline.  It 
is  assumed  that  there  is  no  advantage  to  completing  a  task  before  Its 
deadline.  Thus  response  times  are  not  crucial,  deadlines  of  course  are. 

In  this  quarter  we  have  been  considering  extensions  to  this  work  where 
tasks  can  conflict  with  other  tasks  over  resources  (besides  the  CPU).  We 
have  developed  a  heuristic  for  dealing  with  resource  constraints  and  are  in 
the  process  of  evaluating  the  heuristic. 

In  the  development  of  the  heuristic  we  make  the  following  assumptions: 

1.  When  a  task  arrives,  its  resource  requirements  are  known. 

2.  A  task  also  indicates  whether  it  requires  the  CPU,  some  other 
device,  such  as  an  I/O  device,  or  both. 

3.  Tasks  that  require  CPU  or  devices,  but  not  both,  can  execute 

concurrently. 

Suppose  a  set  of  guaranteed  tasks  exist  on  a  node  and  a  new  task 
arrives.  Our  approach  consideres  that  the  new  task  can  be  guaranteed  only 
if  it  does  not  cause  previously  guaranteed  tasks  to  miss  their  deadlines. 
Because  of  the  overwhelming  computations  needed  to  perform  such  a  check 
exhaustively,  we  need  a  heuristic  approach  which  can  be  summarized  as 
follows:  The  following  heuristic  functionis  applied  to  each  task  in  the 
system,  including  the  newly  arrived  task. 


H(t)  -  K1*X1(t)  +  K2*X2(t)  *  K3*X3(t) 


where  t  is  a  task,  K1 ,  K2  and  K3  are  adaptive  coefficients  and 

1.  XI (t)  takes  into  account  the  resource  and  device  requirements  of 
task  t  as  well  as  the  resource  and  device  utilization, 

2.  X2(t)  takes  into  account  the  laxity  of  task  t,  and 

3-  X3(t)  takes  into  account  the  computation  time  of  task  t. 

We  do  not  describe  the  components  of  the  above  formula  in  detail, 
because  they  still  are  under  development,  but  it  is  important  to  note  that 
these  factors  take  all  the  important  issues  into  account. 

From  the  result  of  the  function  application  to  each  task,  the  task  with 
the  smallest  value  is  chosen  as  a  candidate  to  be  scheduled  first.  Assuming 
that  the  task  would  complete  execution',  i.e.,  releases  resources  and 
devices,  the  heuristic  function  is  applied  again  to  each  of  the  remaining 
tasks  to  determine  the  next  task  to  be  scheduled,  and  so  on.  When  a  task  is 
chosen  to  be  scheduled  next  by  using  function  H(t),  our  algorithm  also 
checks  that  it  is  guaranteed  to  meet  its  requirements.  If  this  fails  for 
any  of  the  tasks  in  the  system,  it  means  that  our  heuristics  did  not  find  a 
way  to  guarantee  all  tasks  in  the  system.  As  a  result,  the  newly  arriving 
task  is  not  guaranteed  and,  of  course,  all  previously  guaranteed  tasks  are 
not  affected. 

The  performance  of  this  technique  is  intimately  related  to  the  ability 
of  the  heuristic  function  to  find  a  good  schedule,  assuming  one  exists. 
Obviously,  the  choice  of  values  for  the  coefficients  will  affect  the 
performance  of  the  heuristic.  The  results  of  the  tests  performed  so  far,  on 
a  set  of  task  samples  by  using  a  properly  tuned  set  of  coefficients,  are 
encouraging.  We  have  observed  that  the  heuristic  guarantees  around  80?  of 
the  tasks,  i.e.,  when  a  set  of  tasks  arrive  and  are  known  (by  exhaustive 
search)  to  be  guaranteeable ,  the  heuristic  technique  just  described 
guarantees  the  tasks  in  80  out  of  100  instances.  To  increase  the  percentage 
of  success  on  a  set  of  tasks,  we  propose  to  adapt  the  coefficients  of  the 
function  using  the  information  derived  from  applying  the  heuristic  to  the 
given  set  of  tasks  and  reapply  the  function  to  the  same  set  of  tasks.  We 
term  this  technique,  by  which  success  on  a  specific  set  of  tasks  can  be 
increased,  as  local  adaptation. 

Since  our  algorithm  is  designed  to  function  in  a  dynamic  environment, 
the  K1 ,  K2  and  K3  values  will  also  have  to  adapt  to  changing  system  loads. 
We  propose  to  continue  our  study  of  the  heuristic  technique  in  the  coming 
months. 


2.3  Stochastic  Learning  Automata 


This  quarter  was  spent  evaluating  simulation  results  produced  as  part 
of  a  masters  thesis,  as  well  as  improving  the  writing  of  one  thesis  itself. 
The  results  produced  so  far  indicate  that  additional  simulations  are 
required  for  statistical  accuracy.  This  should  be  accomplished  within  the 
next  month  at  which  time  the  thesis  can  be  defended.  Details  about  the 
results  themselves  should  be  possible  in  the  next  quarterly  report. 


3.0  Conclusions  and  Recommendations 


In  general  we  are  moving  into  more  and  more  sophisticated  scheduling 
algorithms.  Simulation  studies,  to  date,  have  been  very  encouraging.  We 
hope  to  continue  our  progress  in  understanding  decentralized  scheduling  and 
decentralized  control  in  general.  We  believe  that  the  simulations  to  be 
performed  in  the  future  will  3how  a  level  of  sophistication  not  yet  seen  in 
the  literature.  This  should  continue  to  produce  significant  new  results. 


4.0  Budget 


Spent  prior  to  this  report:  66 , 464 .62 
Current  Budget  for  Third  Year  of  Contract 


Planned 

Actually  Spent 

December  (83) 

4,000 

3,319.21 

January  (84 

4,000 

February 

4,000 
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4,000 
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4,000 

May 

4,000 

June 

7,000 

July 

7,000 

August 

7,000 
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5,000 
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5,000 
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5,000 

Decemeber 

4,3665.38 

Total:  $130,830.00 
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